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Change Process for the Session Initiation Protocol (SIP) 
Status of this Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 


This memo documents a process intended to apply architectural 
discipline to the future development of the Session Initiation 
Protocol (SIP). There have been concerns with regards to new SIP 
proposals. Specifically, that the addition of new SIP features can 
be damaging towards security and/or greatly increase the complexity 
of the protocol. The Transport Area directors, along with the SIP 
and Session Initiation Proposal Investigation (SIPPING) working group 
chairs, have provided suggestions for SIP modifications and 
extensions. 


1. Terminology 


In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 
and "SHOULD NOT", are to be interpreted as described in Keywords [1]. 
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Da 


History and Development 


The IETF’s Session Initiation Protocol (SIP) [3] was originally 
developed for initiation of multimedia sessions. Internet 
multimedia, voice over IP, IP telephony, and SIP have become quite 
popular, both inside IETF and with other standards groups, and the 
applications of SIP have grown. One result of this popularity has 
been a continual flood of suggestions for SIP modifications and 
extensions. The task for IETF management of SIP has been to keep the 
protocol development focused on SIP’s core strengths and the 
applications it does best. 


2.1 The IETF SIP Working Group 


The IETF SIP Working Group has been chartered to be the "owner" of 
the SIP protocol [3], as long as the working group exists. All 
changes or extensions to SIP must first exist as SIP Working Group 
documents. The SIP Working group is charged with being the guardian 
of the SIP protocol for the Internet, and therefore should only 
extend or change the SIP protocol when there are compelling reasons 
to do so. 


Documents that must be handled by the SIP working group include new 
SIP methods, new SIP option tags, new response codes, and new 
standards track SIP headers. With the exception of "P-" headers 
described in Section 4.1, all SIP extensions must be standards track 
and must be developed in the IETF based upon requirements provided by 
the SIPPING Working Group. 


IETF working groups do not live forever; typically, mailing lists 
continue after the working group is concluded. If the SIP Working 
Group has closed and no suitable replacement or follow-on working 
group is active, the Transport Area directors will the use the non- 
working group standards track document process (described in section 
6.1.2 of RFC 2026--IETF Standards Process [2]) using the SIP and 
SIPPING mailing lists and designated experts from the SIP community 
for advice. The IETF will remain the home of extensions of SIP and 
the requirement of standards track action will remain as defined in 
the rest of this document. The rate of growth of extensions of any 
protocol in the IETF is hoped to be low. 


It is appropriate for any working group to develop SIP event packages 
[4], but the working group must have charter approval to do so. The 
IETF will also require (Individual) RFC publication for the 
registration of event packages developed outside the scope of an IETF 
working group. Requirements for publishing event packages are 
described in detail in Section 4.3. 
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2.2 The IETF SIPPING Working Group 


The IETF Session Initiation Protocol Proposal Investigation (sipping) 
Working Group is chartered to be a filter in front of the SIP Working 
Group. This working group will investigate requirements for 
applications of SIP, some of which may lead to requests for 
extensions to SIP. These requirements may come from the community at 
large, or from individuals who are reporting the requirements as 
determined by another standards body. The SIPPING Working Group will 
also not live forever, with similar consideration to the sections 
above. 


The SIPPING Working Group may determine: that these requirements can 
be satisfied by SIP without modifications, that the requirements are 
not sufficiently general to warrant a change to SIP, that the 
requirements justify a change to SIP, or that the requirements should 
be combined with other requirements to solve a more general problem 
or solve the same problem in a more flexible way. 


Because the SIP protocol gets so much attention, some application 
designers may want to use it just because it is there, such as for 
controlling household appliances. SIPPING should act as a filter, 
accepting only requirements which play to the best strengths of SIP, 
such as realtime presence. 


When the SIPPING working group decides on a set of requirements, it 
forwards them to the SIP working group. The SIPPING Working Group 
may also document usage or applications of SIP which do not require 
any protocol extensions. 


The SIPPING working group also acts as a filter for proposed event 
packages as described in Section 4.3. 


3. SIP Change Process 


Anyone who thinks that the existing SIP protocol is applicable to 
their application, yet not sufficient for their task must write an 
individual Internet-Draft explaining the problem they are trying to 
solve, why SIP is the applicable protocol, and why the existing SIP 
protocol will not work. The Internet-Draft must include a detailed 
set of requirements (distinct from solutions) that SIP would need to 
meet to solve the particular problem. The Internet-Draft must also 
describe in detail any security issues that arise from meeting those 
requirements. After the Internet-Draft is published, the authors 
should send a note to the SIPPING Working Group mailing list to start 
discussion on the Internet-Draft. 
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The SIPPING working group chairs, in conjunction with the Transport 
Area Directors, will determine if the particular problems raised in 
the requirements Internet-Draft warrants being added to the SIPPING 
charter based on the mailing list discussion. The SIPPING working 
group should consider whether the requirements can be merged with 
other requirements from other applications, and refine the ID 
accordingly. 


If the chairs and the ADs both feel that the particular new problems 
should be added to the SIPPING Working Group charter, then the ADs 
will present the proposed SIPPING charter modifications to the IESG 
and IAB, in accordance with the usual process for charter expansion. 
If the IESG (with IAB advice) approves of the charter changes, the 
SIPPING working group can then work on the problems described in the 
Internet-Draft. 


In a separate Internet-Draft, the authors may describe a set of 


changes to SIP that would meet the requirements. The Internet-Draft 
would then be passed to the SIP working group for consideration (if 
warranted). The SIP working group is not required to adopt the 


proposed solution from this additional Internet-Draft. 


The SIPPING working group may also evaluate such proposals for 
extensions if the requirements are judged to be appropriate to SIP, 
but are not sufficiently general for standards track activity. The 
SIPPING working group will attempt to determine if the new proposal 
meets the requirements for publication as a "P-" header, as described 
in Section 4.1, within a specific scope of applicability. 


The Transport ADS may, on a case by case basis, support a process in 
which the requirements analysis is implicit and the SIP working group 
requests the addition of a charter item for an extension without a 
full SIPPING process as described. This will be the exception. 


With respect to standardization, this process means that SIP 
extensions come only from the IETF, the body that created SIP. The 
IETF will not publish a SIP extension RFC outside of the processes 
described here. 


The SIP Working Group is required to protect the architectural 
integrity of SIP and must not add features that do not have general 
use beyond the specific case. Also, they must not add features just 
to make a particular function more efficient at the expense of 
simplicity or robustness. 
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Some working groups besides SIPPING generate requirements for SIP 
solutions and/or extensions as well. At the time this document was 
written, these include SIP for Instant Messaging and Presence 
Leveraging Extensions (simple), Service in the PSTN/IN Requesting 
InTernet Service (spirits), and Telephone Number Mapping (enum). 


4. Extensibility and Architecture 


In an idealized protocol model, extensible design would be self- 
contained, and it would be inherent that new extensions and new 
headers would naturally have an architectural coherence with the 
original protocol. 


However, this idealized vision has not been attained in the world of 
standards track protocols. While, interoperability implications can 
be addressed by capabilities negotiation rules, the effects of adding 
features that overlap, or that deal with a point solution and are not 
general, are much harder to control with rules. Therefore, the 
Transport Area calls for architectural guardianship and application 
of Occam’s Razor by the SIP Working Group. 


In keeping with the IETF tradition of "running code and rough 
consensus", it is valid to allow for the development of SIP 
extensions that are either not ready for standards track, but might 
be understood for that role after some running code, or are private 
or proprietary in nature, because a characteristic motivating them is 
usage that is known not to fit the Internet architecture for SIP. We 
call these "P-" headers, for "preliminary", "private", or 
"proprietary". 


There are two key issues to consider with respect to keeping the "P-" 
header extension space "Safe": 


1. Clearly indicating the unarchitected or not-yet understood nature 
of the extension. 


2. Preventing identity conflicts between extensions. 
4.1 Indicating a "P-" Header: 


Use of an "X-" prefix on textual identifiers has been widely used to 
indicate experimental extensions in other protocols. This approach 
is applied in modified form here by use of a "P-" header extension. 
However, there are a number of stronger constraints for "P-" headers, 
including documentation that get Expert and IESG review, and other 
SIP protocol criteria described below. 
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Informational SIP Headers can be registered as "P-" headers if all of 
the following conditions are met: 


1. A designated expert (as defined in RFC 2434 [4]) MUST review the 
proposal for applicability to SIP and conformance to these 
guidelines. The Expert Reviewer will send email to the Transport 
Area Directors on this determination. The expert reviewer can 
cite one or more of the guidelines that haven’t been followed in 
his/her opinion. 


2. The proposed extension MUST NOT define SIP option tags, response 
codes, or methods. 


3. The function of the proposed header MUST NOT overlap with current 
or planned chartered extensions. 


4. The proposed header MUST be of a purely informational nature, and 
MUST NOT significantly change the behavior of SIP entities which 
support it. Headers which merely provide additional information 
pertinent to a request or a response are acceptable. If the 
headers redefine or contradict normative behavior defined in 
standards track SIP specifications, that is what is meant by 
significantly different behavior. 


5. The proposed header MUST NOT undermine SIP security in any sense. 
The Internet Draft proposing the new header MUST address security 
issues in detail as if it were a Standards Track document. Note 
that, if the intended application scenario makes certain 
assumptions regarding security, the security considerations only 
need to meet the intended application scenario rather than the 
general Internet case. In any case, security issues need to be 
discussed for arbitrary usage scenarios (including the general 
Internet case). 


6. The proposed header MUST be clearly documented in an (Individual 
or Working Group) Informational RFC, and registered with IANA. 


7. An applicability statement in the Informational RFC MUST clearly 
document the useful scope of the proposal, and explain its 
limitations and why it is not suitable for the general use of SIP 
in the Internet. 


Any implementation of a "P-" header (meaning "not specified by a 
standards-track RFC issued through the SIP Working Group") MUST 
include a "P-" prefix on the header, as in "P-Headername". Note that 


"P-" extensions are not IETF standards of any kind, and MUST NOT be 
required by any production deployment considered compliant to IETF 
specifications. Specifically, implementations are only SIP compliant 
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if a) they fall back to baseline behavior when they ignore all P- 
headers, and b) when using P- headers they do not contradict any 
normative behavior. 


4.2 Preventing Identity Conflicts Between P-Extensions: 


In order to prevent identity conflicts between P-headers, this 
document provides an IANA process (See: "IANA Considerations" below) 
to register the P-headers. The handling of unknown P-headers is to 
ignore them, however, section 4.1 is to be taken seriously, and users 
of P-headers will have best results with adherence. All implemented 
P-headers SHOULD meet the P-Header requirements in 4.1. Any P-header 
used outside of a very restricted research or teaching environment 
(such as a student lab on implementing extensions) MUST meet those 
requirements and MUST be documented in an RFC and be IANA registered. 
IANA registration is permitted when the IESG approves the internet- 
draft. 


4.3 SIP Event Packages 


events [4] defines two different types of event packages: normal 
event packages, and event template-packages. Event template-packages 
can only be created and registered by the publication of a Standards 
Track RFC (from an IETF Working Group). Normal event packages can be 
created and registered by the publication of any Working Group RFC 
(Informational, Standards Track, Experimental), provided that the RFC 
is a chartered working group item. 


Individuals may also wish to publish SIP Event packages. Individual 
proposals for registration of a SIP event package MUST first be 
published as Internet-drafts for review by the SIPPING Working Group, 
or the working group, mailing list, or expert designated by the 
Transport Area Directors if the SIPPING Working Group has closed. 
Proposals should include a strong motivational section, a thorough 
description of the proposed syntax and semantics, event package 
considerations, security considerations, and examples of usage. The 
author should submit his or her proposal as an individual Internet- 
Draft, and post an announcement to the working group mailing list to 
begin discussion. The SIPPING Working Group will determine if the 
proposed package is a) an inappropriate usage of SIP, b) applicable 
to SIP but not sufficiently interesting, general, or in-scope to 
adopt as a working group effort, c) contrary to similar work planned 
in the Working Group, or d) should be adopted as or merged with 
chartered work. 
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The IETF requires (Individual) RFC publication for registration of 
event packages developed outside the scope of an IETF working group, 
according to the following guidelines: 


1. A designated expert (as defined in RFC 2434 [4]) MUST review the 
proposal for applicability to SIP and conformance with these 
guidelines. The Expert Reviewer will send email to the IESG on 
this determination. The expert reviewer can cite one or more of 
the guidelines that have not been followed in his/her opinion. 


2. The proposed extension MUST NOT define an event template-package. 


3. The function of the proposed package MUST NOT overlap with 
current or planned chartered packages. 


4. The event package MUST NOT redefine or contradict the normative 
behavior of SIP events [4], SIP [3], or related standards track 
extensions. 


5. The proposed package MUST NOT undermine SIP security in any 
sense. The Internet Draft proposing the new package MUST address 
security issues in detail as if it were a Standards Track 
document. Security issues need to be discussed for arbitrary 
usage scenarios (including the general Internet case). 


6. The proposed package MUST be clearly documented in an 
(Individual) Informational RFC, and registered with IANA. The 
package MUST document all the package considerations required in 
Section 5 of SIP events [4]. 


7. If determined by the expert reviewer or the chairs or ADs of the 
SIPPING WG, an applicability statement in the Informational RFC 
MUST clearly document the useful scope of the proposal, and 
explain its limitations and why it is not suitable for the 
general use of SIP in the Internet. 


5. Security Considerations 


Complexity and indeterminate or hard to define protocol behavior, 
depending on which of many extensions operate, is a fine breeding 
ground for security flaws. 


All Internet-Drafts that present new requirements for SIP must 
include a discussion of the security requirements and implications 
inherent in the proposal. All RFCs that modify or extend SIP must 
show that they have adequate security and do not worsen SIP’s 
existing security considerations. 
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6. IANA Considerations 


RFC 3261 [3] directs the Internet Assigned Numbers Authority (IANA) 
to establish a registry for SIP method names, a registry for SIP 
option tags, and a registry for SIP response codes, and to amend the 
practices used for the existing registry for SIP headers. 


With the exception of P-headers, entries go into these registries 
only by approval of an Internet-Draft as a standards track RFC. 


Each RFC shall include an IANA Considerations section which directs 
IANA to create appropriate registrations. Registration shall be done 
at the time the IESG announces its approval of the draft containing 
the registration requests. 


Standard headers and messages MUST NOT begin with the leading 
characters '"P-". 


"P-" header names MUST begin with the leading characters "P-". No 
"p-" header which conflicts with (would, without the "P-" prefix have 
the same name as) an existing standards track header is allowed. 

Each registration of a "P-" header will also reserve the name of the 


header as it would appear without the "P-" prefix. However, the 
reserved name without the "P-" will not explicitly appear in the 
registry. It will only appear if there is a later standards track 
document (which is unlikely in most cases!). Please do not accept 
the registration of IANA-Greeting when you see: P-IANA-Greeting. 
P-header's "reserved standard names" MUST NOT be used in a SIP 
implementation prior to standardization of the header. 


Short forms of headers MUST only be assigned to standards track 
headers. In other words, P-headers MUST NOT have short forms. 


Similarly, RFC 3265 [4] directs the IANA to establish a registry for 
SIP event packages and SIP event template packages. For event 
template packages, entries go into this registry only by approval of 
a draft for standards track RFC. For ordinary event packages, 
entries go into this registry only by approval of a draft for RFC (of 
any type). In either case, the IESG announcement of approval 
authorizes IANA to make the registration. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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